IN THE CLAIMS 



Please make the following amendments to the claims: 

1. (Currently Amended) A method comprising: 

providing a partition on an Integrated Device Electronics ("IDE") storage device 
of a computer system, wherein said partition is invisible to an operating system of the 
computer system unless the partition is unlocked; 

providing a software task having knowledge about a proper handshake to 
unlock the partition such that the partition that was previously invisible to the 
operating system becomes visible to the operating system; 

establishing a proper unlock handshake between the software task and an IDE 
controller for controlling the storage device; and 

unlocking the partition in response to an unlock request received from the 
software task after the software task performs having knowledge about the handshake 
to unlock the partition, wherein the partition is visible to the operating system when 
unlocked. 

2. (Previously Presented) The method of claim 1, wherein the storage device is a 
hard disk drive having an IDE disk controller. 

3. (Canceled) 

4. (Currently Amended) The method of claim 31, wherein the software task 
requests a master token from the IDE controller when the computer system is first 
turned on and the unlock handshake between the software task and the IDE controller 
is established by passing the master token back to the IDE controller as a parameter. 

5. (Original) The method of claim 2, wherein the software task requests a master 
token from the disk controller when the computer system is first turned on, said master 
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token is used by the software task to initiate the proper handshake to unlock the 
partition. 

6. (Canceled) 

7. (Currently Amended) The method of claim 31, wherein the software receives a 
usage token from an IDE controller when the partition is unlocked and the access 
handshake between the software and the IDE controller is established by passing the 
usage token back to the IDE controller as a parameter. 

8. (Original) The method of claim 1, further comprising locking the partition in 
response to a lock request received from a software having knowledge about a proper 
handshake for locking the partition. 

9. (Original) The method of claim 1, further comprising providing a standard 
partition on the storage device, wherein said standard partition is always visible to the 
operating system and generally accessible to other softwares. 

10. (Previously Presented) A machine-readable medium that provides instructions, 
which when executed by a set of processors, causes said set of processors to perform 
operations comprising: 

receiving an open request from a software to access a secure-private partition on 
an IDE hard drive of a computer system; 

validating the open request received from the software; 

requesting unlocking of the secure-private partition in response to the validation 
of the open request received from the software; 

unlocking the secure-private partition in response to the unlocking request such 
that the partition that was previously invisible to an operating system becomes visible 
to the operating system; and 
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preventing an access to the secure-private partition when the secure-private 
partition is unlocked unless the access is requested by a software having knowledge 
about a proper access handshake for accessing the secure-private partition. 

11. (Original) The machine-readable medium of claim 10, wherein the operations 
further comprise requesting locking of the secure-private partition in response to a close 
request received from the software. 

12. (Original) The machine-readable medium of claim 10, wherein the requesting of 
the unlocking of the secure partition further comprises: 

requesting a master token from an IDE controller when the computer system is 
turned on; 

storing the master token in a secure storage location; 

retrieving the master token from the secure storage location when an access to a 
secure-private partition is needed; and 

passing the master token as a parameter to the IDE controller. 

13. (Original) The machine-readable medium of claim 10, wherein the operations 
further comprise requesting an access to the secure-private partition in response to an 
access request received from the software. 

14. (Original) The machine-readable medium of claim 13, wherein the requesting of 
the access to the secure partition further comprises: 

receiving a usage token; and 

passing the usage token to the IDE controller to gain an access to the secure 
partition. 

15. (Original) The machine-readable medium of claim 10, wherein the request from 
the software to access the secure-private partition is received by a privacy gatekeeper 
which prescreens the request to determine if the software has an authorization to access 
the secure-private partition. 
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16. (Previously Presented) A system comprising: 

a storage device having a storage controller, said storage device having at least 
one secure-private partition, wherein said secure-private partition is selectively in one 
of locked and unlocked modes, wherein said secure-private partition is invisible to an 
operating system when it is locked and the secure-private partition is visible to the 
operating system when it is unlocked; 

an IDE controller operatively coupled to the storage controller; and 
a security /privacy software task operatively coupled to the IDE controller, 
wherein said IDE controller initiates an unlock request to unlock the secure-private 
partition in response to a valid unlock handshake established between the IDE 
controller and the security /privacy software task and said IDE controller initiates a lock 
request to lock the secure-private partition in response to a valid lock handshake 
established between the IDE controller and the security /privacy software task. 

17. (Original) The system of claim 16, wherein the security /privacy software task 
requests a master token from the IDE controller when the system is turned on and 
sends the master token to the IDE controller as a parameter when making a request to 
the IDE controller to unlock the secure-private partition. 

18. (Original) The system of claim 16, further comprising a requesting software and 
a privacy gatekeeper which acts as a gatekeeper to the security /privacy software task, 
wherein when the requesting software makes a request to access the secure-private 
partition, the privacy gatekeeper prescreens the request to determine if the requesting 
software has an authorization to access the secure-private partition. 

19. (Original) The system of claim 18, wherein the IDE controller allows an access to 
said at least one secure-private partition only when a valid access handshake is 
established between the requesting software and the IDE controller. 

20. (Canceled) 
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21. (Previously Presented) The method of claim 1, further comprising: 
preventing an access to the partition when the partition is unlocked unless the access is 
requested by a software having knowledge about a proper access handshake for 
accessing the partition. 

22. (Previously Presented) The system of claim 16, wherein the IDE controller 
generates and return a usage token to the requesting software once the secure-private 
partition is unlocked, wherein the access handshake is established between the IDE 
controller and the requesting software when the IDE controller validates the usage 
token passed back by the requesting software. 

Please add the following new claims 

—23. (New) A method comprising: 

partitioning a hard disk into a standard partition and a secure-private partition 
(SPP), the SPP operable in a locked mode and an unlocked mode; 

switching the SPP from the locked mode to the unlocked mode in response to a 
handshake; 

receiving at least one read/write request from a requesting software program; 

and 

switching the SPP from the unlocked mode to the locked mode in response to a 
close request; wherein 

each of the at least one read/write requests is accompanied by a usage token. 

24. (New) The method of claim 23 wherein the handshake comprises: 
receiving a secure token from a requesting software program; 
verifying the secure token; and 

returning a usage token to the requesting software program. 
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25. (New) The method of claim 23, further comprising: 

validating the usage token received with a read/write request, and, if the token 
is valid, performing the request; or 

if the token is invalid, denying the request. 

26. (New) The method of claim 23, further comprising: 
generating a new usage token after the read /write request; and 

returning the new usage token to the requesting software program. — 
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